Legacy:Making Mods/General Mod Optimization

Here I will outline some easy and commonly overlooked methods for optimizing your mod so that it performs at its best. I encountered all of these myself while producing Frag.Ops, and being my first mod I realized how easy it is to not notice these things. Currently a work in progress. -SquirrelZero

Mesh LOD - UT200X

Mesh LOD (Level Of Detail) levels and their benefits.

Player Models

For each of your player models, you should have 4 LOD levels. These can be viewed in the LOD drop-down menu in the Animation Browser. LOD levels are what the engine will display at varying view distances from the model, to save polygon counts that the viewer would otherwise never notice. Each level collapses certain polygons on the model to create a lower-poly version of the original. When importing your models into the editor, these levels are generated for you. However, if you saved them with smoothing groups, the engine will generally collapse parts of the model that you really don't want it to collapse – like the neck, ankles, elbows, wrists, etc. This causes pieces of the model to be completely see-through at a relatively short view distance. Make sure you don't save any player models with smoothing groups.

Vehicles

These are generally the same as Player Models. No need for further explanation.

1st and 3rd Person Weapon Models

Here you only need 1 LOD level: the original mesh. Since the editor automatically creates the 4 levels for you when importing a model, this is often the most overlooked setting I've come across. You can safely delete levels 1,2, and 3, thus reducing the total data size by a very large amount. When preloading each model, all of the LOD levels are preloaded along with it, and by deleting these you can reduce the memory usage often by almost a megabyte per 1st person model, and 200-300 kilobytes per 3rd person model. In cases of high memory usage, this can make a world of difference.

Rigidize - UT200X

The rigidize subcategory of LOD levels, used for reducing the overhead when drawing a skeletal mesh.

Player Models

This is somewhat of a topic of contention among modders. Open the Animation Browser and go to the first level of LOD in any stock UT200X player model. You'll see a subsection named Rigidize. There is a variable here named MeshSectionMethod. You'll notice that on all UT200X player models, they're set to MSM_SmoothOnly. This basically tells the engine "This mesh has no rigid parts, and should be reuploaded to the video card each time the model needs to be repainted." Sound slow? It is. In fact, it's the slowest of all the Rigid settings. So why do all the stock models use it? Most player models have very few rigid parts and are generally deformable on the whole. For example, if you set it to MSM_RigidOnly then click the Redigest LOD button, you'll only see the rigid parts, which are very few and don't make up large chunks of the polycount. Obviously using MSM_RigidOnly would be a bad idea, since you wouldn't want to see only those small patches of the model in the game. MSM_Mixed tells the engine "This model has both smooth and rigid parts, so cache some of it to memory while reuploading the rest." However, using this on a model with very few rigid parts can actually decrease performance, since the CPU overhead needed to compute these configurations would outweigh the benefit.

So when is it a good idea to use MSM_Mixed on a player model? Say your killer new model is a mechanical one, like a robot, with very few deformable parts – let's say, a Star Wars AT-ST. Machines generally don't deform because they're made of metal. In this case, you would probably see an excellent benefit from using the MSM_Mixed rigid setting, since it will allow your model to be almost entirely cacheable to video memory, like a static mesh. This means the video card would require less overhead per tick when rendering that model, allowing a substantial performance increase. This and the MSM_RigidOnly setting are also common on Vehicles in UT2004, which I'll get to next.

Vehicles

Vehicles can almost always use MSM_RigidOnly. Very few vehicles will need to deform, except perhaps ones like the LawDogs horses or the Shattered Oasis cows. This is used extensively in UT2004 to boost performance in maps where sometimes there are as many as 10-15 vehicles on screen at once.

1st Person Weapon Models

Here's a good time to make use of the MSM_Mixed and MSM_RigidOnly settings. Since most weapons don't deform, you can safely use MSM_RigidOnly in almost all situations. This basically allows your weapons to be entirely cacheable to the video card, and is much, much faster than reuploading the entire mesh each repaint, especially when compared with models at high polycounts. The only time you wouldn't want to use this setting is if your models also included some kind of arm or hand holding them, since these need to deform and can't be rigid. Here it is safe to use MSM_Mixed because the weapon itself takes up a large chunk of the polycount, and is not deformable.

3rd Person Weapon Models

Ah, here we introduce a new rigid setting: MSM_SinglePiece. This is similar to MSM_RigidOnly, except forces the model to always use the reference pose (no animation). Nearly all 3rd person weapon/inventory models can use this setting. This setting performs nearly as good as static meshes, with the small exception of the mesh skeleton. The reason 3rd person weapon models are skeletal meshes at all is because they can use bones, which are very handy for attaching effects like shell ejectors and muzzle flashes, things that would otherwise be very difficult to code in. Note that MSM_SinglePiece is the fastest of all the Rigid settings.

Conclusion

This is by no means complete, but I do need some sleep now :). I'll be adding a few more tips this week, and I intend to link the relevant sections to their counterparts elsewhere on the wiki.

---

----

EntropicLqd: Can you explain deformable a little more clearly. Is it the same as animated? In which case the Flak Cannon would be deformable? or is it something else? interesting page btw. Very nice.

Foxpaw: I believe deformable refers to a group of vertices that do not change position relative to each other. So, for instance, some parts of the flak cannon are animated, but all parts of the piston head (and I believe the shell too) stay in the same place relative to each other, as do the "body" pieces. However, in, say, a player, the "skin" of the player changes considerably as it moves.

Foxpaw: Also, should this page be merged with Optimization Techniques?

SquirrelZero: Ah, I didn't see that page. It might fit in quite nicely there. Foxpaw is correct, deformable refers to models that stretch and bend, like the legs on a player model when running, or the twisting of the torso. The model's structure changes often and so needs to be reuploaded to memory with each change.

Dirk Fist: Rubber == Deformable; Porcelain != Deformable :D